25장. 로컬 RAG 만들기

1. 로컬 AI와 RAG를 결합한다는 것

앞 장에서는 로컬 AI 성능을 이해하기 위해 CPU, GPU, VRAM, 모델 크기, 양자화, 동시 요청 처리 같은 개념을 살펴보았다.

이제 로컬 AI를 조금 더 실무적으로 활용해보자.

로컬 AI를 단순히 챗봇처럼 쓰는 것도 가능하다.

사용자 질문
→ 로컬 LLM
→ 답변 생성

하지만 이 방식만으로는 한계가 있다.

로컬 LLM도 기본적으로 모델이 학습한 범위 안에서 답변한다.
우리 회사의 내부 문서, 운영 매뉴얼, 장애 대응 절차, 고객센터 정책, 개발 가이드는 모델이 알지 못한다.

예를 들어 로컬 모델에게 이렇게 물어본다고 해보자.

우리 회사에서 하트 충전 미반영 문의는 어떻게 처리해?

모델은 일반적인 결제 문의 처리 방법을 그럴듯하게 말할 수는 있다.
하지만 실제 회사 내부 정책을 모른다면 정확한 답변을 할 수 없다.

이때 필요한 것이 RAG다.

RAG는 질문과 관련된 문서를 먼저 검색한 뒤, 그 문서를 근거로 AI가 답변하게 하는 방식이다.

사용자 질문
→ 관련 문서 검색
→ 검색된 문서를 로컬 LLM에 전달
→ 문서 기반 답변 생성

클라우드 AI로도 RAG를 만들 수 있지만, 로컬 AI와 결합하면 외부 AI API를 사용하지 않고 내부 문서 기반 질문 답변 시스템을 만들 수 있다.

사내 문서
→ 내부 임베딩 모델
→ 내부 벡터DB
→ 로컬 LLM
→ 문서 기반 답변

이 장에서는 클라우드 없이 로컬 환경에서 RAG를 구성하는 방법을 살펴본다.

2. 로컬 RAG가 필요한 이유

로컬 RAG가 필요한 대표적인 이유는 데이터 보안이다.

사내 문서에는 외부로 보내기 어려운 내용이 많다.

- 운영 매뉴얼
- 장애 대응 절차
- 내부 API 문서
- DB 구조 문서
- 보안 정책
- 고객센터 응대 가이드
- 관리자 기능 설명서
- 서비스 장애 리포트
- 내부 회의록

이런 문서를 클라우드 AI API로 보내는 것이 부담스러울 수 있다.

특히 다음과 같은 경우에는 로컬 RAG가 좋은 선택지가 될 수 있다.

- 문서를 외부 AI API로 전송하기 어렵다.
- 사내망 안에서만 동작해야 한다.
- 내부 문서 검색을 AI로 개선하고 싶다.
- 클라우드 AI 비용을 줄이고 싶다.
- 민감한 로그나 정책 문서를 기반으로 답변해야 한다.
- PoC 단계에서 로컬 환경으로 빠르게 실험하고 싶다.

예를 들어 개발팀 문서 검색 도우미를 만든다고 해보자.

개발자:
"배포 실패 시 rollback 절차 알려줘."

로컬 RAG:
내부 배포 매뉴얼 검색
→ 관련 절차 추출
→ 로컬 LLM이 답변 생성
→ 출처 문서 표시

이 구조에서는 내부 문서가 외부 AI API로 전송되지 않는다.

또 운영팀 매뉴얼 검색에도 활용할 수 있다.

운영자:
"결제 콜백 timeout이 발생하면 먼저 뭘 확인해야 해?"

로컬 RAG:
장애 대응 매뉴얼과 결제 연동 문서 검색
→ 확인 항목 정리
→ 운영자에게 답변

로컬 RAG는 단순히 “로컬 모델로 챗봇 만들기”가 아니다.

내부 문서를 검색하고, 그 문서를 근거로 답변하며, 외부 전송 없이 동작하는 사내 지식 검색 구조다.

3. 로컬 RAG의 기본 구성 요소

로컬 RAG를 만들려면 몇 가지 구성 요소가 필요하다.

기본 구성은 다음과 같다.

문서
→ 문서 파서
→ chunk 분할
→ 임베딩 모델
→ 벡터DB
→ 검색
→ 로컬 LLM
→ 답변

각 구성 요소의 역할은 다음과 같다.

흐름을 질문 답변 기준으로 보면 다음과 같다.

1. 사용자가 질문한다.
2. 질문을 임베딩으로 변환한다.
3. 벡터DB에서 의미가 비슷한 문서 chunk를 찾는다.
4. 검색된 문서를 프롬프트에 넣는다.
5. 로컬 LLM이 답변을 생성한다.
6. 답변과 출처를 사용자에게 보여준다.

예를 들어 사용자가 이렇게 질문했다고 하자.

하트 충전 후 반영이 안 될 때 고객센터는 어떻게 안내해야 해?

검색 결과로 다음 문서 chunk가 나왔다고 해보자.

문서 1:
충전 미반영 처리 절차

문서 2:
결제 승인 후 고객 응대 가이드

문서 3:
환불 요청 기준

이제 로컬 LLM에게 다음처럼 전달한다.

아래 참고 문서만 사용해서 질문에 답해라.
문서에 없는 내용은 추정하지 말고 "문서에서 확인할 수 없습니다"라고 답해라.
답변 마지막에 사용한 문서 제목을 표시해라.

질문:
하트 충전 후 반영이 안 될 때 고객센터는 어떻게 안내해야 해?

참고 문서:
[문서 1] 충전 미반영 처리 절차
...
[문서 2] 결제 승인 후 고객 응대 가이드
...

로컬 LLM은 이 문서를 바탕으로 답변한다.

이것이 로컬 RAG의 기본 구조다.

4. 로컬 임베딩 모델

RAG에서 임베딩 모델은 매우 중요하다.

임베딩 모델은 문장이나 문서를 숫자 벡터로 바꾼다.
이 벡터를 사용해 질문과 의미가 비슷한 문서를 찾는다.

문서:
"하트 충전 후 반영되지 않는 경우 결제 승인 여부를 확인한다."

임베딩 모델:
[0.13, -0.02, 0.88, ...]

사용자 질문도 같은 방식으로 벡터로 바꾼다.

질문:
"충전했는데 하트가 안 들어왔어요. 어떻게 처리해?"

임베딩 모델:
[0.11, -0.01, 0.84, ...]

두 벡터가 가까우면 의미가 비슷하다고 판단한다.

로컬 RAG에서는 임베딩도 외부 API가 아니라 로컬 모델로 처리할 수 있다.

문서
→ 로컬 임베딩 모델
→ 벡터 생성
→ 로컬 벡터DB 저장

로컬 임베딩 모델을 선택할 때는 다음을 확인해야 한다.

- 한국어 검색 품질이 괜찮은가
- 문서와 질문의 의미를 잘 연결하는가
- 실행 속도가 충분한가
- CPU로도 실행 가능한가
- 벡터 차원이 너무 크지 않은가
- 라이선스 문제가 없는가

특히 한국어 문서 검색에서는 임베딩 모델 품질이 중요하다.

예를 들어 사용자는 이렇게 질문할 수 있다.

충전했는데 하트가 안 들어왔어요.

문서에는 이렇게 적혀 있을 수 있다.

결제 승인 후 서비스 내 재화가 미반영되는 경우 결제 승인 상태와 지급 처리 로그를 확인한다.

표현은 다르지만 의미는 비슷하다.

좋은 임베딩 모델은 이런 표현 차이를 어느 정도 연결해준다.

임베딩 품질이 나쁘면 RAG 전체 품질이 떨어진다.

질문은 맞게 들어왔지만
→ 관련 문서를 못 찾음
→ 로컬 LLM이 엉뚱한 문서로 답함
→ 사용자는 AI를 신뢰하지 않음

RAG에서는 LLM만 중요한 것이 아니다.
임베딩 모델과 검색 품질이 답변 품질의 출발점이다.

5. 로컬 벡터DB

임베딩으로 만든 벡터는 저장하고 검색할 수 있어야 한다.

이때 사용하는 것이 벡터DB다.

벡터DB는 문서 chunk의 벡터와 원문, 메타데이터를 함께 저장한다.

예를 들어 하나의 chunk는 다음처럼 저장될 수 있다.

{
  "chunkId": "chunk_001",
  "documentId": "doc_payment_guide",
  "title": "충전 미반영 처리 절차",
  "content": "결제 승인 후 하트가 반영되지 않는 경우...",
  "embedding": [
    0.13,
    -0.02,
    0.88
  ],
  "metadata": {
    "department": "customer-center",
    "version": "2026-05-01",
    "allowedRoles": [
      "cs",
      "admin"
    ]
  }
}

사용자가 질문하면 질문도 임베딩으로 바꾸고, 벡터DB에서 가까운 chunk를 찾는다.

질문 임베딩
→ 벡터DB 검색
→ 관련 chunk 3~5개 반환

로컬 RAG에서 사용할 수 있는 벡터 저장소는 여러 가지가 있다.

- FAISS
- Chroma
- Qdrant
- PostgreSQL + pgvector
- SQLite 기반 간단한 저장소

초보자가 실습할 때는 Chroma나 FAISS처럼 가볍게 시작할 수 있는 도구가 편하다.

운영이나 사내 도구로 확장할 계획이 있다면 PostgreSQL + pgvector 또는 Qdrant 같은 구성을 고려할 수 있다.

각 방식은 장단점이 있다.

로컬 RAG를 처음 만든다면 너무 복잡한 벡터DB부터 시작할 필요는 없다.

먼저 작은 문서 세트로 흐름을 확인하는 것이 좋다.

1. Markdown 문서 몇 개 준비
2. chunk 분할
3. 임베딩 생성
4. 로컬 벡터DB 저장
5. 질문으로 검색 테스트
6. 로컬 LLM 답변 생성

흐름을 이해한 뒤, 문서 수와 사용자가 늘어나면 운영형 벡터DB를 고려하면 된다.

6. 문서 수집과 정제

RAG 품질은 문서 품질에 크게 영향을 받는다.

좋은 모델을 써도 문서가 엉망이면 좋은 답변이 나오기 어렵다.

문서 수집 단계에서는 먼저 어떤 문서를 RAG에 넣을지 정해야 한다.

- 개발 문서
- 운영 매뉴얼
- 고객센터 가이드
- 장애 대응 절차
- API 명세
- 보안 가이드
- FAQ

문서를 무조건 많이 넣는 것이 좋은 것은 아니다.

오래된 문서, 중복 문서, 작성 중인 초안, 틀린 문서가 섞이면 검색 품질이 떨어진다.

문서가 많음
→ 검색 대상 증가
→ 오래된 문서가 검색될 수 있음
→ AI 답변이 잘못될 수 있음

따라서 문서 정제가 필요하다.

정제할 내용은 다음과 같다.

- 중복 문서 제거
- 오래된 문서 제외 또는 낮은 우선순위 부여
- 제목 없는 문서 정리
- 목차와 섹션 구조 정리
- 불필요한 HTML 태그 제거
- 광고, 메뉴, 푸터 제거
- 이미지 캡션이나 표 내용 보완
- 문서 소유자와 수정일 추가

예를 들어 운영 매뉴얼이 다음처럼 되어 있다면 검색 품질이 나빠질 수 있다.

제목 없음
작성일 없음
담당자 없음
내용 중간에 과거 정책과 현재 정책이 섞여 있음

좋은 문서는 다음 정보를 갖는다.

문서 제목:
충전 미반영 처리 절차

소유 부서:
고객센터 / 결제 담당

수정일:
2026-05-01

상태:
운영 중

내용:
절차, 예외, 담당자, 관련 시스템 링크

RAG는 문서 검색 시스템이다.
따라서 문서 관리가 곧 AI 품질 관리다.

7. 문서 분할 전략

긴 문서를 그대로 임베딩하면 검색 품질이 떨어질 수 있다.

예를 들어 50페이지 운영 매뉴얼 전체를 하나의 벡터로 만들면, 사용자의 특정 질문과 정확히 매칭되기 어렵다.

그래서 문서를 작은 단위로 나눈다.

이 단위를 chunk라고 부른다.

긴 문서
→ chunk 1
→ chunk 2
→ chunk 3
→ ...

예를 들어 장애 대응 매뉴얼을 다음처럼 나눌 수 있다.

chunk 1:
장애 등급 정의

chunk 2:
장애 발생 시 최초 대응

chunk 3:
담당자 연락 절차

chunk 4:
장애 보고서 작성 방법

chunk 크기가 너무 크면 검색 결과가 뭉뚱그려진다.

너무 큰 chunk:
여러 주제가 섞임
정확한 검색이 어려움
AI에게 불필요한 내용까지 전달

chunk 크기가 너무 작으면 문맥이 부족해진다.

너무 작은 chunk:
문장 일부만 검색됨
앞뒤 맥락이 부족함
답변 생성이 어려움

그래서 적당한 크기를 찾아야 한다.

일반적인 기준은 다음과 같다.

- 한 chunk에는 하나의 주제가 들어가게 한다.
- 제목과 섹션 정보를 함께 저장한다.
- 너무 짧은 문장은 앞뒤와 묶는다.
- 표나 절차는 중간에 끊지 않는다.
- chunk overlap을 적절히 둔다.

chunk overlap은 chunk 사이에 일부 내용을 겹치게 넣는 방식이다.

chunk 1:
A, B, C

chunk 2:
C, D, E

이렇게 하면 문맥이 끊기는 것을 줄일 수 있다.

chunk overlap은 문서를 나눌 때 앞뒤 chunk 사이에 일부 내용을 겹치게 넣는 방식이다.
문맥이 중간에서 끊기는 문제를 줄이기 위해 사용한다.

문서 분할은 RAG 품질에 매우 중요하다.
검색이 잘 안 된다면 모델보다 chunk 전략을 먼저 의심해야 한다.

8. 메타데이터 저장

RAG에서는 문서 내용뿐 아니라 메타데이터도 중요하다.

메타데이터는 문서에 대한 부가 정보다.

예를 들어 다음과 같은 정보가 있다.

- 문서 제목
- 문서 ID
- 작성자
- 소유 부서
- 작성일
- 수정일
- 문서 버전
- 문서 상태
- 접근 권한
- 카테고리
- 원본 URL 또는 파일 경로

메타데이터가 있으면 검색과 운영이 훨씬 쉬워진다.

예를 들어 사용자가 고객센터 정책을 질문했다면 고객센터 문서만 우선 검색할 수 있다.

질문:
하트 환불 기준 알려줘.

검색 범위:
category = customer-center
department = payment

문서가 오래되었는지도 확인할 수 있다.

문서 A:
수정일 2023-01-01

문서 B:
수정일 2026-05-01

동일 주제라면 문서 B 우선

접근 권한도 메타데이터로 관리할 수 있다.

{
  "documentId": "doc_refund_policy",
  "title": "환불 정책",
  "department": "customer-center",
  "allowedRoles": [
    "cs",
    "admin"
  ],
  "updatedAt": "2026-05-01"
}

사용자가 질문하면 사용자의 역할에 따라 검색 범위를 제한한다.

사용자 role:
developer

검색 대상:
allowedRoles에 developer가 포함된 문서만

출처 표시에도 메타데이터가 필요하다.

답변:
하트 사용 전 상태에서는 환불 가능하지만,
이미 사용한 하트는 환불이 제한됩니다.

출처:
- 환불 정책, 2026-05-01 수정

메타데이터가 없으면 RAG는 단순 검색 기능에 머문다.
메타데이터가 있어야 실무형 RAG가 된다.

9. 로컬 RAG의 질문 답변 흐름

이제 로컬 RAG의 전체 질문 답변 흐름을 하나로 묶어보자.

사용자 질문
→ 질문 임베딩 생성
→ 벡터DB 검색
→ 관련 chunk 선택
→ 프롬프트 구성
→ 로컬 LLM 호출
→ 답변 검증
→ 출처와 함께 반환

예를 들어 사용자가 이렇게 질문했다고 해보자.

하트 충전 후 반영이 안 될 때 고객에게 뭐라고 안내해야 해?

1단계는 질문 임베딩이다.

질문
→ 로컬 임베딩 모델
→ 질문 벡터

2단계는 벡터 검색이다.

질문 벡터
→ 벡터DB 검색
→ 관련 chunk 5개 반환

3단계는 권한과 관련성 필터링이다.

- 사용자가 볼 수 있는 문서인가?
- 관련성 점수가 충분한가?
- 오래된 문서는 아닌가?
- 중복 문서는 아닌가?

4단계는 프롬프트 구성이다.

너는 고객센터 상담원을 돕는 AI다.
아래 참고 문서만 사용해서 질문에 답해라.
문서에 없는 내용은 추정하지 말고 "문서에서 확인할 수 없습니다"라고 답해라.
답변 마지막에 사용한 문서 제목을 표시해라.

질문:
하트 충전 후 반영이 안 될 때 고객에게 뭐라고 안내해야 해?

참고 문서:
[문서 1] 충전 미반영 처리 절차
...
[문서 2] 결제 승인 확인 가이드
...

5단계는 로컬 LLM 호출이다.

프롬프트
→ 로컬 LLM
→ 답변 생성

6단계는 응답 검증이다.

- 답변이 비어 있지 않은가?
- 문서에 없는 내용을 단정하지 않았는가?
- 출처가 포함되었는가?
- 민감 정보가 포함되지 않았는가?

최종 응답은 다음처럼 만들 수 있다.

답변:
하트 충전 후 반영되지 않은 경우 먼저 결제 승인 여부와 서비스 내 충전 반영 상태를 확인해야 합니다.
승인 문자를 받았지만 서비스에 반영되지 않았다면 결제 승인 후 미반영 처리 절차에 따라 담당 부서 확인이 필요합니다.

출처:
- 충전 미반영 처리 절차
- 결제 승인 확인 가이드

이 흐름이 로컬 RAG의 기본이다.

10. 문서에 없는 질문 처리하기

RAG에서 가장 중요한 원칙 중 하나는 문서에 없는 내용을 지어내지 않는 것이다.

사용자가 이렇게 질문했다고 해보자.

다음 달 하트 할인 이벤트 일정 알려줘.

그런데 RAG에 등록된 문서에는 이벤트 일정이 없다.

이때 AI가 다음처럼 답하면 안 된다.

다음 달 첫째 주에 하트 할인 이벤트가 진행될 예정입니다.

문서에 없는 내용을 만들어낸 것이다.

좋은 답변은 다음과 같다.

제공된 문서에서는 다음 달 하트 할인 이벤트 일정을 확인할 수 없습니다.
이벤트 일정은 별도 공지 문서나 운영 담당 부서 확인이 필요합니다.

이를 위해 프롬프트에 명확한 규칙을 넣어야 한다.

아래 참고 문서에 있는 내용만 사용해 답변해라.
문서에 없는 내용은 추정하지 마라.
문서에서 확인할 수 없는 경우 "제공된 문서에서는 확인할 수 없습니다"라고 답해라.

또 검색 결과가 없거나 관련성 점수가 낮을 때는 LLM을 호출하지 않고 바로 답할 수도 있다.

검색 결과 없음
→ "관련 문서를 찾지 못했습니다" 반환

이 방식은 비용도 줄이고 환각도 줄인다.

나쁜 방식:
검색 결과가 없어도 LLM 호출
→ 모델이 일반 지식으로 답변
→ 환각 위험

좋은 방식:
검색 결과가 없으면 답변 생성 중단
→ 문서 없음 안내

RAG의 신뢰도는 “잘 답하는 능력”뿐 아니라 “모를 때 모른다고 하는 능력”에서 나온다.

11. 로컬 RAG에서 권한 관리

로컬 RAG도 권한 관리가 필요하다.

외부 클라우드로 데이터를 보내지 않는다고 해서 모든 문제가 해결되는 것은 아니다.

내부 문서라고 해도 모두가 볼 수 있는 것은 아니다.

개발팀 문서:
개발팀만 접근 가능

고객센터 문서:
고객센터와 관리자만 접근 가능

보안 정책 문서:
보안 담당자와 일부 관리자만 접근 가능

인사 문서:
인사팀만 접근 가능

RAG에서 권한 관리는 검색 단계에서 적용해야 한다.

사용자 질문
→ 사용자 권한 확인
→ 권한 있는 문서만 검색
→ 답변 생성

나쁜 구조는 다음과 같다.

전체 문서 검색
→ AI가 답변 생성
→ 사용자에게 표시

이렇게 하면 사용자가 직접 볼 수 없는 문서 내용이 AI 답변을 통해 노출될 수 있다.

좋은 구조는 다음과 같다.

사용자 role 확인
→ allowedRoles 필터 적용
→ 필터링된 문서에서만 검색
→ 답변 생성

예를 들어 사용자가 developer 역할이라면 다음 조건으로 검색한다.

{
  "allowedRoles": {
    "$contains": "developer"
  }
}

또는 부서 기반으로 필터링할 수도 있다.

department in ["platform", "development"]

권한 관리는 로컬 RAG에서 특히 중요하다.

로컬이라는 이유로 보안 검토를 생략하면 내부 정보 유출이 발생할 수 있다.

원칙은 단순하다.

사용자가 직접 볼 수 없는 문서는
AI도 검색하면 안 된다.

12. 로컬 RAG의 장점

로컬 RAG의 장점은 분명하다.

첫 번째는 데이터 통제다.

문서와 질문, 검색 결과, AI 응답이 내부 환경에서 처리된다.

사내 문서
→ 내부 임베딩 모델
→ 내부 벡터DB
→ 로컬 LLM
→ 내부 사용자

두 번째는 민감 문서 활용이다.

클라우드 AI API로 보내기 어려운 문서도 내부에서 처리할 수 있다.

- 운영 로그
- 장애 대응 문서
- 내부 정책 문서
- 개발 문서
- 보안 가이드

세 번째는 비용 예측이다.

클라우드 AI처럼 요청마다 토큰 비용이 발생하지 않는다.
대신 서버 자원 중심으로 비용을 계산할 수 있다.

네 번째는 사내망 운영이다.

외부 인터넷이 제한된 환경에서도 사용할 수 있다.

다섯 번째는 커스터마이징이다.

문서 구조, 검색 방식, 권한 필터, 프롬프트, 모델 선택을 내부 요구사항에 맞게 조정할 수 있다.

장점을 정리하면 다음과 같다.

로컬 RAG는 보안과 내부 지식 활용이 중요한 조직에서 강력한 선택지가 될 수 있다.

13. 로컬 RAG의 한계

로컬 RAG에도 한계가 있다.

첫 번째는 모델 품질이다.

로컬 LLM이 클라우드 고성능 모델보다 답변 품질이 낮을 수 있다.

- 긴 문맥 이해가 부족할 수 있음
- 문서 기반 답변 지시를 잘 따르지 않을 수 있음
- 한국어 답변이 어색할 수 있음
- 문서에 없는 내용을 지어낼 수 있음

두 번째는 검색 품질이다.

임베딩 모델이나 chunk 전략이 좋지 않으면 관련 문서를 못 찾는다.

질문은 정확함
→ 검색 결과가 엉뚱함
→ 답변도 엉뚱함

세 번째는 운영 부담이다.

로컬 RAG는 구성 요소가 많다.

- 문서 수집
- 문서 파싱
- chunk 분할
- 임베딩 생성
- 벡터DB 운영
- 로컬 LLM 운영
- 권한 필터
- 로그와 모니터링

네 번째는 하드웨어 한계다.

로컬 LLM 응답이 느리거나, 동시 요청 처리가 어려울 수 있다.

다섯 번째는 문서 관리 문제다.

RAG는 문서가 최신이어야 잘 동작한다.

문서가 오래됨
→ 오래된 정책으로 답변
→ 운영 사고 가능

로컬 RAG는 클라우드 비용과 외부 전송 문제를 줄일 수 있지만, 그만큼 내부 운영 책임이 커진다.

따라서 처음부터 전사 규모로 만들기보다는 작은 문서 범위로 시작하는 것이 좋다.

14. 로컬 RAG를 처음 만들 때 추천하는 순서

처음 로컬 RAG를 만들 때는 작게 시작해야 한다.

추천하는 순서는 다음과 같다.

1. Markdown 또는 TXT 문서 10~30개를 준비한다.
2. 문서 제목, 수정일, 소유자를 정리한다.
3. 문서를 chunk로 나눈다.
4. 로컬 임베딩 모델로 벡터를 만든다.
5. 로컬 벡터DB에 저장한다.
6. 질문을 넣어 관련 문서가 잘 검색되는지 확인한다.
7. 검색 결과를 로컬 LLM에 전달해 답변을 만든다.
8. 답변에 출처를 붙인다.
9. 문서에 없는 질문을 테스트한다.
10. 권한 필터를 추가한다.
11. 응답 품질과 속도를 측정한다.

처음부터 PDF 수천 개를 넣는 것은 좋지 않다.

문제가 생겼을 때 원인을 찾기 어렵다.

답변이 이상함
→ 문서 문제인가?
→ chunk 문제인가?
→ 임베딩 문제인가?
→ 검색 문제인가?
→ LLM 문제인가?

작은 문서 세트로 시작하면 문제를 추적하기 쉽다.

예를 들어 다음처럼 시작할 수 있다.

문서 범위:
고객센터 충전/환불 문서 20개

목표:
하트 충전, 미반영, 환불 관련 질문에 답변

평가 질문:
실제 고객 문의 기반 50개

성공 기준:
관련 문서 검색률 80% 이상
답변에 출처 포함
문서에 없는 질문은 거절

이렇게 범위를 좁혀야 빠르게 개선할 수 있다.

15. 로컬 RAG 평가 기준

로컬 RAG를 만들었다면 반드시 평가해야 한다.

단순히 “답변이 그럴듯하다”로 판단하면 안 된다.

RAG 평가는 크게 두 부분으로 나눌 수 있다.

1. 검색 평가
2. 답변 평가

검색 평가는 관련 문서를 잘 찾았는지 보는 것이다.

질문:
하트 충전 후 미반영 처리 절차는?

기대 문서:
충전 미반영 처리 절차

검색 결과:
기대 문서가 상위 3개 안에 있는가?

답변 평가는 검색된 문서를 바탕으로 제대로 답했는지 보는 것이다.

- 문서에 있는 내용만 사용했는가
- 핵심 절차를 빠뜨리지 않았는가
- 출처를 표시했는가
- 문서에 없는 내용을 지어내지 않았는가
- 답변이 사용자에게 이해하기 쉬운가

평가용 질문 세트를 만들어두면 좋다.

- 실제 자주 묻는 질문 50개
- 문서에 답이 있는 질문 30개
- 문서에 답이 없는 질문 10개
- 권한별로 결과가 달라야 하는 질문 10개

권한 테스트도 중요하다.

개발팀 사용자:
개발 문서만 검색되어야 함

고객센터 사용자:
고객센터 문서만 검색되어야 함

일반 사용자:
내부 제한 문서가 검색되면 안 됨

평가 결과는 기록해야 한다.

RAG는 한 번 만들고 끝나는 기능이 아니다.
문서가 바뀌고, 질문이 쌓이고, 모델이 바뀌면 계속 평가해야 한다.

16. 로컬 RAG 운영 시 주의할 점

로컬 RAG를 운영할 때는 다음을 주의해야 한다.

첫 번째는 문서 최신성이다.

문서가 오래되면 AI 답변도 오래된 정책을 따르게 된다.

오래된 환불 정책 문서
→ 잘못된 환불 안내
→ 고객 응대 문제

문서별 수정일과 상태를 관리해야 한다.

상태:
draft
active
deprecated
archived

검색 대상에는 active 문서만 포함하는 것이 좋다.

두 번째는 재색인이다.

문서가 수정되면 벡터DB도 업데이트해야 한다.

문서 수정
→ 기존 chunk 제거 또는 갱신
→ 새 chunk 생성
→ 임베딩 재생성
→ 벡터DB 업데이트

세 번째는 권한 변경이다.

사용자 권한이나 문서 접근 권한이 바뀌면 검색 결과에도 반영되어야 한다.

네 번째는 로그 관리다.

RAG 질문에는 내부 정보가 포함될 수 있다.

- 고객 문의 내용
- 장애 로그 일부
- 내부 시스템명
- 정책 문서 제목

따라서 원문 질문과 답변을 그대로 저장할지 신중하게 결정해야 한다.

다섯 번째는 모델 변경이다.

로컬 LLM이나 임베딩 모델을 바꾸면 검색 결과와 답변 품질이 달라질 수 있다.

임베딩 모델 변경
→ 기존 벡터 재생성 필요

LLM 변경
→ 답변 문체와 지시 준수 변화

로컬 RAG 운영은 문서, 검색, 모델, 권한, 로그를 함께 관리하는 일이다.

17. 로컬 RAG와 클라우드 RAG 비교

로컬 RAG와 클라우드 RAG는 각각 장단점이 있다.

어느 쪽이 무조건 더 좋다고 할 수 없다.

상황에 따라 다르다.

민감 문서 중심:
로컬 RAG 유리

빠른 PoC:
클라우드 RAG 유리

높은 답변 품질:
클라우드 고성능 모델 유리

사내망 전용:
로컬 RAG 유리

운영 인력 부족:
클라우드 관리형 서비스 유리

세밀한 권한과 검색 제어:
직접 구현 또는 하이브리드 고려

실무에서는 둘을 섞는 것도 가능하다.

문서 검색:
내부 벡터DB에서 수행

답변 생성:
민감 문서는 로컬 LLM
일반 문서는 클라우드 LLM

또는 로컬 RAG를 기본으로 쓰고, 품질이 부족한 질문만 클라우드 모델로 보낼 수도 있다.

로컬 RAG 답변
→ 신뢰도 낮음
→ 사용자 승인 후 클라우드 모델로 재질문

중요한 것은 데이터 민감도, 비용, 품질, 운영 부담을 함께 고려하는 것이다.

18. 정리

로컬 RAG는 내부 문서 기반 AI 검색을 외부 AI API 없이 구성하는 방식이다.

기본 구조는 문서를 수집하고, chunk로 나누고, 로컬 임베딩 모델로 벡터를 만들고, 벡터DB에 저장한 뒤, 사용자 질문과 관련된 문서를 검색해 로컬 LLM이 답변하는 흐름이다.

로컬 RAG의 장점은 데이터 통제다.
사내 문서, 운영 매뉴얼, 보안 정책, 개발 문서처럼 외부로 보내기 어려운 자료를 내부에서 처리할 수 있다.

하지만 로컬 RAG는 단순히 벡터DB와 로컬 LLM을 붙이면 끝나는 기능이 아니다.

문서 품질, chunk 전략, 임베딩 모델, 벡터DB, 권한 필터, 출처 표시, 문서 최신성, 재색인, 로그 정책을 함께 설계해야 한다.

특히 권한 관리는 중요하다.

사용자가 직접 볼 수 없는 문서는 AI도 검색하면 안 된다.
로컬 환경이라고 해서 권한 검사를 생략하면 내부 정보 유출이 발생할 수 있다.

로컬 RAG는 작은 문서 세트로 시작하는 것이 좋다.
처음부터 모든 사내 문서를 넣기보다, 고객센터 정책이나 개발 문서처럼 범위를 좁혀 검색 품질과 답변 품질을 검증해야 한다.

이 장에서 기억해야 할 핵심은 하나다.

로컬 RAG는 “클라우드 없이 문서 검색 AI를 만드는 기술”이지만,
실제 품질은 모델보다 문서 관리, 검색 설계, 권한 제어, 출처 표시에서 결정된다.

25장 핵심 요약